Adding Google Tag Manager Functionality #76
Conversation
There was a problem hiding this comment.
Looks great @warrenhbrown! On your site I see that the Google Tag Manager script is loaded into the <head>. Looks great!
@specify/dev-testing We need to edit the settings.json file and add a line that sets gtmContainerId to a Google Tag Manager container ID (it accepts a string). We need to confirm that it does nothing when not configured. If we insert a container ID, it should load the GTM script into the <head>.
|
Hi all, thanks for considering these updates. I just wanted to add that the search-related event tracking changes are limited to Advanced search, as that is the default preference for our institution. We can add that same functionality to the Express search to capture the queries if you think there's value there too. Just let know. Thanks again. |
There was a problem hiding this comment.
To my understanding, it looks like anyone wishing to utilize the dataLayer needs to define these specific events or variables pushed to the dataLayer via the Google Tag Manager.
(See https://support.google.com/tagmanager/answer/6164391?hl=en and https://developers.google.com/tag-platform/tag-manager/datalayer)
If there are any further steps required for setting this up completely which are outside of the normal WebPortal configuration, could you please expand on them so documentation regarding this new functionality can be properly written?
| window.dataLayer.push({ | ||
| 'event': 'search_query', | ||
| 'searchQuery': filterStr | ||
| }); |
| window.dataLayer.push({ | ||
| 'event': 'image_detail', | ||
| 'attachmentId': imgRecord.data.AttachmentID, | ||
| 'attachmentTitle': imgRecord.data.Title | ||
| }); |
| window.dataLayer.push({ | ||
| 'event': 'record_detail', | ||
| 'catalogNumber': record.data.catalogNumber | ||
| }); |
|
Correct. Automatically collected events and enhanced event measurement are far simpler implementations and would have been our preference. Unfortunately, these only work with traditional websites with full page reloads or single page applications that reflect state changes in the URL as a visitor interacts with them. This doesn't appear to be the case with this version of the Web Portal. So we went the custom event route, which is admittedly tailored to our needs here and can add a significant amount of complexity in terms of wiring up GTM, GA, and all the custom reporting interfaces to capture these. Now even without these events, it is still possible to collect valuable insights beyond what is currently available — metrics such as session lengths, unique users, tech platforms, etc. So perhaps it makes more sense to remove these custom events from the codebase, while leaving the gtm.js script intact for the wider community. Then each institution can decide how exactly they'd like to configure custom events, if at all. I would refer to Google's documentation for configuring GTM/GA wiring:
And for custom events, this is a very detailed guide that I found to be helpful: |
This pull request adds support for Google Tag Manager (GTM) so a Web Portal instance may report search and click events to Google Analytics. GTM may be configured with the "gtmContainerId: Google Tag Manager container ID" in settings.json.
We wish to share this functionality with the global community of Web